AWS cafeteria #1 に「クラウドの落とし穴：AWS Backupで発生した高額請求の衝撃とその教訓」というタイトルで登壇しました
2024.01.25こんにちは、AWS事業本部の平木です！
本日、「AWS cafeteria #1 〜サイバーエージェント×ゆめみ×クラスメソッド 3社共催LT会〜」で運営メンバー兼登壇者としてLTしてきたため登壇資料を公開いたします。
登壇資料
こちらから登壇資料をご覧いただけます。
導入
※一部スライドを割愛しながら記載いたします。
みなさんは何かで1位を取ったことはありますか？
自分はつい最近、社内（厳密には部署内）で1位になったことがあります。
こちらは弊社Slack内では週次で投稿されるとあるランキングのスクリーンショットですが、
1番上が1位で、2位と比べると圧倒的な1位ですね。
こちらが何のランキングを表しているかと言うと…
社内個人検証環境のAWS利用金額のランキングです。
当時のドル円換算をするとなんと、約330万円！
なぜこんなことが起きてしまったのか、起きてしまった後どのような対処をしたのかなどを共有できればと思います。
高額請求発生の背景
2023年11月27日、re:Invent期間中にAWS Backupにて自動復元テストと呼ばれる機能が追加されました。
こちらの機能を簡単に解説すると、
AWS Backupで取得したバックアップを目標復旧時間（RTO）を満たしているかを自動かつ定期的に検証を実施してくれる機能です。
詳細は下記ブログでも紹介していますのでご興味ある方は読んでみてください。
12月某日この新機能を試すために下記条件で検証を開始しました。
- 対象： EC2インスタンス1台（t2.micro）
- バックアップ取得タイミング： 1時間毎
- 復元テストタイミング： 1時間毎
非常にシンプルな条件のため下記のように、単純にバックアップと復元テストの一連の流れができる想定でした。
しかし、期待とは裏腹に特定の条件下の場合、再帰的なループが発生してしまう罠がありました。
具体的には、復元テストが生成したリソースをバックアッププランがバックアップ対象として実行してしまい、気づくと指数関数的にEC2の起動処理とリカバリポイントの生成が行われました。
その特定の条件下というのは、
- バックアッププランと復元テストプランの実行時間帯が一致
- バックアッププランの対象に復元テストプランで生成されるリソースが含まれる
- バックアッププランで復元テストが生成するリソースのタグを除外していない
の3つです。
これらの条件が重なり、結果として
EC2インスタンス： 12,750台
リカバリーポイント：10,356個
が生成される事態となってしまいました。
たった1台の検証用EC2インスタンスからここまでになってしまうなんて恐ろしいですね。
日次のAWS利用額の通知は実装していたものの、
「土日（休日）を挟んでいたこと」
「リソースが急増したのが検証2日目だったこと」
が重なり気づいたころには高額請求が発生していました。
AWSサポートとのやりとり
高額請求発生に気づき、まず3つの観点で対処を行いました。
権限のはく奪
まず1つ目はバックアッププランで使用されていたサービスロールの権限をはく奪することで、
AWS Backupにバックアップを行う権限とリストアする権限をなくしました。
ここで表記されている AWSBackupDefaultServiceRole とは、
AWS Backupがサポートしているすべての AWS サービスに対してのバックアップオペレーションを実行するためにAWS Backupが必要とする権限を持っています。
こちらの公式ドキュメントで詳細は確認できます。
エビデンスの取得
続いて2つ目では、急にリソースを削除し始めるのではなく、
後で設定をしっかり確認できるようにスクリーンショットを撮りました。
この情報の取得があとで活きてきます。
リソースの削除
最後3つ目は、削除開始までの準備を終えたので実際に削除を行い始めました。
保留中となっているバックアップジョブが大量に滞留していたため手作業での削除は早々に無理と判断し、
AWS CLIを使用しAWS CLIの結果からAWS CLIを実行するようにfor文でループさせるようにしました。
プログラム的に処理することでスムーズに削除できました。
当時コマンド作成する際には下記ブログを参考にしました。
(レポート) DEV301: AWS CLIによる自動化 #reinvent | DevelopersIO
AWSサポートへ問い合わせ
このような形でひとまずの対処が完了したため、
続いてはAWSサポートへの料金関連のご相談をするためサポートケースを起票しました。
当時、下記を意識してAWSサポートに対して情報提供とお願いをしました。
その後、AWSサポートからは次の情報提供を求められました。
料金の減免に関する申請は、公私共に初めてだったためこういった情報を提供するべきなのかと勉強になりました。
ちなみに再発防止として既にコストアラート系の実装済だったので別の対策案を検討しました。
Service Quotasの中にEC2のオンデマンドインスタンスの起動数に関する項目Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instancesがあるため、
こちらに関するアラートを作成し、EC2の異常起動を検知できるようにしました。
この項目の詳細については下記をご参照ください。
On-Demand Instances - Amazon Elastic Compute Cloud
そういったやり取りもあり、約1か月待った結果なんと…
無事、今回高額請求となったAWS BackupとEC2サービスの当時の利用料金を全額免除していただけました！
（AWSさんに圧倒的感謝っ・・・・！）
各フェーズにおける教訓
ここで高額請求を経験し得た教訓を皆様へも共有します。
平常時
まず平常時ですが、コストアラートの実装と特にAWS Cost Anomaly Detectionを活用することは
個人検証環境であっても重要だと思いました。
AWS Budgetsによってコストアラートを、AWS Cost Anomaly Detectionを利用してコストの異常検知を行えます。
詳しくは下記ブログを参照ください。
高額請求発覚直後
ひとまず一呼吸おいて焦らずにエビデンスの取得をしましょう。
スクリーンショット取る程度であれば全て取るにしても1分程度で出来るため設定値はすぐ見返せるようにしておくと良いです。
あとでCloudTrailで調査でも大丈夫ですが、新規APIとなる場合は調査が容易ではありません。
原因対処完了後
リソースを全て削除して落ち着いたら、集められる限りの情報を整理し、
AWSサポートへ相談しましょう。
その時も投げやりな質問ではなく、なるべく会話の往復のやり取りが少なく済むような質問の仕方をできると良いと思います。
一般的には、5W1Hを意識した情報提供を意識できていれば問題ないと思います。
まとめ
まとめとなりましたが、これだけは覚えて帰ってほしい！ということを3つ書きだしました。
まずこういったことは他人事ではない！といったことです。
AWSやその他クラウドサービスを使っていればいつかこういった事態に遭遇する可能性はゼロではないです。
日頃から意識をしてコスト管理をしましょう。
また、そういった事態が起きても焦らないことです。
焦りは余計なことをしてしまう要因となりうるため一回落ち着きましょう。
最後はエビデンスは可能な限り取得しましょう。
細かく取っておくことでどうしてこうなってしまったかの分析がしやすくなります。
焦ってしまうとここが抜け落ちてしまうのでまずは落ち着いてパラメータを控えたほうが良いです。
おわりに
今回は、AWS cafeteria #1といったイベントで「クラウドの落とし穴：AWS Backupで発生した高額請求の衝撃とその教訓」というタイトルで登壇してきたため登壇内容を公開いたしました。
今回は設定による高額請求でしたがセキュリティインシデントが発生した場合に遭遇する高額請求も同様かと思います。
これから同じ境遇にあった方がこの記事で少しでも安心して対処いただけると嬉しいです。
